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ABSTRACT 



Apparatus and method for receiving alarms from multiple 
network management servers and applying a plurality of 
policy-based filters to the alarms. The filters may be named 
and stored in a database, and application of the policy-based 
filters may be scheduled for different times. The same 
policy-based filters may be applied to one or more multiple 
network management applications. The invention allows 
greater control over which alarms get reported to network 
management applications and provides a means to ensure 
consistency of reported alarms across multiple network 
management applications. 

33 Claims, 9 Drawing Sheets 
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METHOD AND APPARATUS FOR POLICY- 
BASED ALARM NOTIFICATION IN A 
DISTRIBUTED NETWORK MANAGEMENT 
ENVIRONMENT 

5 

This application is a continuation of U.S. application Sen 
No. 09/110,564, filed Jul. 6, 1998, now U.S. Pat. No. 
6,057,757, which is a continuation of U.S. application Ser. 
No. 08/412,955 filed Mar. 29, 1995, now U.S. Pat. No. 
5,777,549. 10 

FIELD OF THE INVENTION 

The present invention relates to alarm notification in a 
communications network and more specifically to a method 
and apparatus for receiving alarms from multiple network is 
management servers, applying policies to those alarms and 
forwarding the alarms that conform to the policies to one or 
more network management applications. 

BACKGROUND OF THE INVENTION 

20 

Spectrum™ is a model-based network management 
system, sold by Cabletron Systems, Inc., Rochester, N.H., 
for maintaining and processing information pertaining to the 
condition of a communications network and providing the 
same to a user. For example, Spectrum™ will periodically 2 $ 
poll a network device to request information, such as the 
number of packets sent on the network in a given time and 
the number of errors that occurred. If the error rate is above 
a predetermined limit, an error alarm is logged in the 
Spectrum™ database, an alarm sent to the user interface to 30 
notify the network manager, and a message is sent to shut off 
the corresponding network device. 

Alternatively, if no response was received from the net- 
work device when it was polled, the reason for the loss of 
contact should be determined so that appropriate action, 35 
such as a service call, can be taken. In a network 
environment, loss of contact with a network device may be 
due to failure of that network device or to failure of another 
network device that is involved in the transmission of a 
message. 40 

In many prior art network management systems, the 
network administrator was typically provided with a list of 
possible causes of a fault and was required to isolate the fault 
based on his experience and knowledge of the network. In 
Spectrum™, the system itself isolates network defaults 45 
using a technique known as Status Suppression. Spectrum™ 
maintains a database of models for each network device. 
When contact between a model and its corresponding net- 
work device is lost, the model sets a fault status and initiates 
the fault isolation technique. The model (first model) which 50 
lost contact with its corresponding network device (first 
network device) determines whether adjacent models have 
lost contact with their corresponding network devices; adja- 
cent network devices are defined as those which are directly 
connected to a specified network device. If adjacent models 55 
cannot contact the corresponding network devices, then the 
first network device cannot be the cause of the fault, and its 
fault status in the first model will be overriden. By sup- 
pressing the fault status of the network devices which are 
determined not to be defective, the defective network device 60 
can be identified. Once the fault has been isolated, the 
condition of the defective device can be updated in the 
Spectrum™ database, a control message can be sent shutting 
off the defective device, and the network administrator can 
be notified via the user interface. 55 

Spectrum™^ associated SpectroGRAPH™ user inter- 
face provides a graphical view into the network models. An 



alarm log view, shown in FIG. 1, includes an area 120 for the 
listing of current alarms, and an area 122 for displaying 
information pertaining to a selected alarm. The user may 
click on a particular alarm in the listing of current alarms to 
obtain more information. A multi-function icon 124 repre- 
senting the network device having a fault is displayed in area 
122, with one or more text fields 126 and 128 which provide 
information to the user regarding the cause of the alarm and 
the status of the device. By clicking on specified areas of the 
icon 124, the user can obtain further information regarding 
the device for which an alarm is registered. 

Another method for fault management in large commu- 
nications networks is to use a so-called "trouble-ticketing" 
system. This system provides a number of tools that can be 
used by network users, administrators, and repair and main- 
tenance personnel. The basic data structure, a " trouble - 
ticket", has a number of fields in which a user can enter data 
describing the parameters of an observed network fault. A 
trouble-ticket filled out by a user may then be transmitted by, 
for example, an electronic mail system to maintenance and 
repair personnel. A trouble -ticket describing a current net- 
work fault that needs to be acted on is called "an outstanding 
trouble-ticket". When the network fault has been corrected, 
the solution to the problem, typically called a "resolution" is 
entered into an appropriate data field in the trouble -ticket 
and the trouble-ticket is said to be completed. The system 
provides for storage of completed trouble-tickets in memory 
and thus a library of such tickets is created, allowing users, 
administrators, and maintenance and repair personnel to 
refer to the stored completed trouble -tickets for assistance in 
determining solutions to future network faults. An example 
of a trouble-ticketing system is the ACTION REQUEST 
system, developed by Remedy Corporation, Mountain View, 
Calif., and sold by Cabletron Systems, Inc., Rochester, N.H. 

ARS Gateway™ is a network management application 
sold by Cabletron Systems, Inc. which receives fault infor- 
mation from the Spectrum™ system and automatically 
generates a trouble-ticket that may be processed by the 
ACTION REQUEST system. This system is further 
described in copending and commonly owned U.S. Ser. No. 
08/023,972 filed Feb. 26, 1993 by Lundy Lewis, and entitled 
"Method and Apparatus For Resolving Faults In Commu- 
nications Networks," and which is hereby incorporated by 
reference in its entirety. 

The Spectrum™ system is described in U.S. Pat. No. 
5,261,044 issued Nov. 9, 1993 to Roger Dev et al., which is 
hereby incorporated by reference in its entirety. The Spec- 
trum™ network management system is commercially avail- 
able and also described in various user manuals and litera- 
ture available from Cabletron Systems, Inc., Rochester, N.H. 

Other network management platforms and applications 
for the basic filtering of alarms which are commercially 
available include: (1) HP OpenView, 3000 Hanover Street, 
Palto, Calif. 94304; (2) LattisNet, SynOptics 
Communications, 4401 Great American Pkwy., Santa Clara, 
Calif. 95054; (3) IBM Netview/6000, IBM Corp., Old 
Orchard Road, Armonk, N.Y. 10504; and (4) SunNet 
Manager, SunConnect, 2550 Garcia Ave, Mountain View, 
Calif. 94043. 

Unfortunately, in the prior art systems alarms can only be 
received from one network management server. Also there is 
no provision for applying the same policy-based filter to 
multiple network management applications. 

Thus, it is an object of the present invention to provide 
greater control over which alarms get reported to network 
management applications and to provide a means to ensure 
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consistency of reported alarms across multiple network 
management applications. 

SUMMARY OF THE INVENTION 

The present invention is directed to an apparatus and 5 
method of alarm notification, which includes: (a) receiving 
alarms from multiple network management servers; (b) 
assigning policy-based filters to associated network man- 
agement applications; and (c) applying the assigned policy- 
based filters to the alarms and for the alarms that pass the 10 
filters, generating an alarm notification forwarding the same 
to the associated network management applications. 

In an embodiment described herein, a user designates a 
plurality of such filters, which constitute an alarm notifica- 
tion policy, to one or more associated network management 
applications. The policy-based filters are stored in a 
database, and a tag is assigned for identifying each filter. The 
same filters may be assigned to multiple applications. 

In a further embodiment, the user may schedule the 2Q 
assignment of such policy-based filters to occur at a desig- 
nated time in the future. For example, a user may pick a 
policy from a list of available policies to associate with a 
selected application, and then designate the frequency with 
which the policy is applied, e.g., once, hourly, daily, weekly 25 
or monthly. 

Furthermore, the invention can be used in the same mode 
as similar tools in the prior art, i.e., with one alarm- 
forwarding component for each network management 
system/network management application pair, or alterna- 30 
tively as a single entity in a distributed network management 
environment. 

These and other features of the present invention will be 
more fully described in the following detailed description 
and figures. 35 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is an example of an alarm log display provided by 
the prior art Spectrum™ network management system. 

40 

FIG. 2 is a block diagram of an alarm notification man- 
ager in accordance with the present invention, in use with 
multiple network management servers and multiple network 
management applications. 

FIG. 3 is a flow chart illustrating the application of 45 
policy-based filters to an alarm, and forwarding of the alarm 
which passes the filters to an application in accordance with 
this invention. 

FIG. 4 is an example of an Associations window display 
of the alarm notification manager. 50 

FIG. 5 is an example of a New Association window 
display of the alarm notification manager. 

FIG. 6 is an example of a Modified Association window 
display for the alarm notification manager. 

FIG. 7 is an example of a Scheduler window display for 55 
the alarm notification manager. 

FIG. 8 is an example of a Policies window display for the 
alarm notification manager. 

FIG. 9 is an example of an Open Policy window display 6Q 
for the alarm notification manager. 

FIG. 10 is an example of an Add Filter Values window 
display for the alarm notification manager. 

FIG. 11 is an example of an Alarm Age window display 
for the alarm notification manager. 55 

FIG. 12 is an example of a New Policy window display 
for the alarm notification manager. 
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FIG. 13 is a block diagram illustrating two separate 
processes between the network management application and 
the alarm notification manager. 

FIG. 14 is a block diagram illustrating a central process- 
ing unit and memory for use in this invention. 

DETAILED DESCRIPTION 

The present invention is directed to an alarm notification 
manager which receives alarms from multiple network man- 
agement servers, allows an unlimited number of filters to be 
defined within one policy, allows policies to be named and 
stored in a database, allows policies to be scheduled for 
different times, and allows the same policy to be applied to 
one or more network management applications. 

As illustrated in FIG. 2, a live network 10 is connected by 
links 11 to one or more network management servers 12 
which monitor the network. The servers detect errors or 
faults on the network and send alarm information to the 
alarm notification manager 14 via links 13. The alarm 
notification manager includes a policy database 16, method 
for applying policies to alarms 18, graphical interface 20, 
and scheduler 22. The manager applies policy-based filters 
to the alarm messages received from the servers, and for 
those alarms which pass the filter criteria, an alarm message 
is sent to the appropriate network management application 
24 via links 23. 

In a specific embodiment described herein, a plurality of 
distributed SpectroServers™, part of the Spectrum™ system 
sold by Cabletron Systems, Inc., Rochester, N.H., are used 
to model the live network 10, and several Spectrum™ 
applications receive the filtered alarm messages from, the 
manager 14. These components have been implemented in 
the object-oriented programming language C++. However, 
the invention is not tied to any particular language nor to any 
particular products used in network management. 
The Spectrum™ Network Management System 

An understanding of the present invention is furthered by 
an understanding of the model -based network management 
system known as Spectrum™, which is described in U.S. 
Pat. No. 5,261,044, issued Nov. 9, 1993 to R.Dev et al., and 
hereby incorporated by reference in its entirety. The Spec- 
trum™ network management system is commercially avail- 
able and also described in various user manuals and litera- 
ture available from Cabletron Systems, Inc., Rochester, N.H. 

In summary, Spectrum™ is a system for maintaining and 
processing information pertaining to the condition of the 
computer network and providing the same to a user, the 
network including a plurality of network entities such as 
computer devices and software applications being executed 
on such devices. The system includes a virtual network 
machine, comprising a programmed digital computer, 
wherein a program is implemented using an object-oriented 
programming language such as C++, Eiffel, SmallTalk, and 
Ada. The virtual network consists of interrelated intelligent 
models of network entities and relations between network 
entities, including means for acquiring network data per- 
taining to the condition of a network entity from the corre- 
sponding network entity. The virtual network further 
includes means for maintaining objects which include net- 
work data relating to the corresponding network entity and 
one or more inference handlers for processing the network 
data, the inference handlers being responsive to changest 
occurring in the same and/or a different object. The network 
data can then be transferred to a user interface coupled to the 
virtual network machine, for supplying the network data to 
a user. 



12/09/2003, EAST Version: 1.4.1 



US 6,373,383 Bl 



Thus, the models are implemented as software "objects" 
containing both "data" (attributes) relating to the corre- 
sponding network entity and one or more "inference han- 
dlers" (functions) for processing the data. See Grady Booch, 
"Object-Oriented Analysis And Design, With Applications," 5 
2nd Edition, Benjamin/Cummings Publishing Co,, Red- 
wood City, Calif., Chapter 2, 1994. The inference handlers 
are initiated by predetermined virtual network events, such 
as a change in specified network data in the same model, a 
change in specified network data in a different model, and 10 
predefined events or changes in models or model relations. 
Information pertaining to the condition of the network entity 
can be obtained from the network entity by polling the same, 
can be automatically received from the network entity 
(without polling), or can be inferred from data contained in 15 
other models. An alarm condition may be generated when 
the network data meets a predetermined criteria. Events, 
alarms and statistical information from the virtual network 
are stored in a database and are selectively displayed for the 
user. 20 

The data in the Spectrum™ database may be used for 
generating topological displays of the network, showing 
hierarchial relationships between network devices, isolating 
a network fault, and reviewing statistical information. 

Spectrum'™ allows for collective management of autono- 2 5 
mous local area networks (LANs), with equipment from 
different vendors. It complies with the current Simple Net- 
work Management Protocol (SNMP) standards, and can also 
accommodate other standard and proprietary protocols. The 
virtual network machine preprocesses the raw information 3Q 
coming from the network devices in order to construct a 
model of the network's current status and performance 
characteristics. Network elements that cannot be directly 
communicated with (e.g., cables and buildings) can infer 
their status from the status of the devices connected to (or 
contained within) them. The virtual network machine pro- 35 
vides a consistent interface for management applications to 
access any of the information in the model and thereby 
provides these applications with a unified view of the 
network. 

Spectrum's™ associated SpectroGRAPH™ user inter- 40 
face provides a highly graphical multi-perspective view into 
the network model. SpectroGRAPH™ enables the user to 
navigate through a landscape in which cables, networks, 
local area networks and even rooms show up as icons, and 
which icons indicate the health and performance character- 45 
istics of those elements. These icons can be further queried 
for additional information. SpectroGRAPH™ 's main func- 
tion is to visually present to the user the model within the 
virtual network machine. It allows the user to navigate freely 
within the network model, only limited by the access rights 
assigned by the network administrator. The information can 
be accessed at varying degrees of detail, from a macro 
overview, to the devices and cables which connect them. In 
addition to its navigation functions, SpectroGRAPH™ pro- 
vides an alarm management facility, an event log window, a 
reporting facility, a find facility, and other features. 55 

The above description of the Spectrum™ system provides 
a context for an understanding of the present invention. 
The Alarm Notification Manager 

The following definitions are helpful to an understanding 
of the present invention: 60 



-continued 





is associated. A policy may consist 




of one or more filters. 


Filter 


A set of filter parameters and 




associated filter values. Multiple 




filters define multiple sets of 




values for the filter parameters. 


Filter Parameter 


A data type such as model name or IP 




subnet for which the user can specify 




a value or list of values. SANM 




provides the user with a fixed list 




of filter parameters. 


Association 


When the user associates a policy 




with an application, he is specifying 




the filter criteria that SANM should 




apply to the alarms it sends to the 




application. 



SANM 
Policy 



SPECTRUM ™ Alarm Notification Manager 
A set of criteria which a given alarm 
must satisfy in order to be passed to 
the application with which the policy 



A filter consists of a list of filter parameters and a list of 
associated filter values. A user (of a network management 
application) specifies the value(s) that each filter parameter 
can take in order for a given alarm to pass the filter criteria. 
The following is a list of representative filter parameters: 

model name 

model type name 

device IP subnet 

device location 

alarm severity 

alarm age 

SpectroSERVER host name 
landscape name 
alarm cause 

The value for each of the above filter parameters would be 
received from Spectrum™, except for the alarm age param- 
eter. The alarm age parameter is used internally by SANM 
and specifies the length of time that it should hold an alarm 
before sending it to an application. If the alarm is cleared by 
Spectrum™ during this time, it is not sent to the application. 
This feature may be used to filter out transient alarms. 

Each filter value also has a corresponding flag which 
indicates whether it should be negated. For example, if the 
negate flag is set for a model type name value of Hub_ 
CSLJRM3, this filter value states that all alarms for models 
NOT of type Hub__CSI_lRM3 should pass. 

More complex filtering can be achieved by defining 
multiple filters within a policy. Each filter specifies a sepa- 
rate set of filter values. 

SANM performs a logical AND of all the filter criteria 
within a filter and performs a logical OR between all filters 
within a policy. 

For example, a policy contains two filters as follows: 
Filter 1 

Model Type: Rtr_Cisco 

Landscape: wiz 
Filter 2 

Model Type: Rtr_Wellfleet 

Landscape: brat 

SANM would apply this policy to a given alarm as 
follows: 

IF the alarm has: 

model type Rtr_Cisco AND landscape wiz OR 
model type Rtr_Wellfleet AND landscape brat 
THEN send the alarm to the application. 
Each filter also contains a filter tag, which is a text string 
that the user enters. This tag, which is included in the alarm 
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notification, identifies which filters) passed and can be used 2.1 Associations Window 

by an application to perform routing of alarms. . . , , c . • j 

p. ^ m „ t ^ o ,,o„r ™„ u 0 „„t*™wi ;„ tu» When the Configuration Tool is invoked, the first window 

ror example, a dirierent user name can be entered in the . . ... . . , . ^ w -, * ^ . 

Alter tag field of each filter, so that if the criteria in one filter l0 . a PP car » s tl ! e Associations window, shown m FIG. 4. This 

pass, the application will notify a particular user, whereas if 5 windcw display* a In* of the currently defined SANM 

the criteria in another filter pass, the application will notify jjPPbcaUons ™d the policy that is associated with each of 

a different user. If multiple filters pass, a list of correspond- em ' 

ing filter tags is sent in the alarm notification. A new association is created by selecting New from the 

Another example of the SANM filtering mechanism is File menu. ™ s brings up the New Association window 

shown in FIG. 3. In this figure, the criteria listed within each 10 shown in FIG. 5. 

filter are the criteria for which values have been specified by An existing association is modified by selecting the 

the user. It can be seen from this example that all filters are association and then selecting Modify from the File menu, 

applied in parallel to a given alarm (i.e., a logical OR is This brings up the Modify Association window shown in 

performed between filters). However, all criteria within a FIG. 6. 

given filter must be satisfied for the alarm to pass the filter 15 An existing association is deleted by selecting the asso- 

(i.e., a logical AND is performed between the criteria within ciation and then selecting Delete from the File menu. The 

a given filter). Since, in this example, the alarm passes the selected association is deleted after the user confirms the 

criteria in filters 1 and 3, an alarm notification containing operation in a Confirmation Dialog window (not shown), 

filter tags "A" and "C" is sent to the application. ^ modiflcation of an existing association can be sched- 

Pohcies and the associations ^een policies and apph- 20 uled b selectin the ^ and then se]eclin Schedule 

cations are stored in the SPECTRUM™ database. This from the pfle menu ^ bfin tfae Scheduler wimJow 

means that the same policies are available to any client shown in FIG 7 

machine running SANM. It also means that the policy names , ' ' , . 

contained in event messages logged by SANM have signifi- _ ^! ™™ntly defined policies can be viewed by selecting 

t~ „n „u ant ^u-jV ' a cnrrTDrT\/fTM „ r Policies from the loo Is menu. This brings up the Policies 

c an ce to all client machines using the same o PLC I RUM rM 25 . , f . „ & r 



database. 

1.0 Alarm Notification 



window shown in FIG. 8. 

2.2 New Association Window 



4 - . , . , . , « A »tw Th c New Association Window is illustrated in FIG. 5. In 
After an application has registered with SANM to receive mis window , a n ^ ^ from the list of avai iable 
alarms, an alarm notification is sent t^at application each licies and the application namc ^ entered When 0K is 
time an alarm is received from SPECTRUM™ that passes pressed> thc wimkw disappcars and the new aasocMoa 
the criteria specified in the policy associated with that ^ (hc j^^^ window (FIG . 4) . 
application. The information contained in each alarm noti- 
fication consists of the real-time values of each filter 2.3 Modify Association Window 

parameters, plus the values of the following parameters: 35 ^ „ 

model handle e k* 0 " 1 ^ Assoda 11011 window is illustrated in FIG. 6. 

In this window, the user picks a policy from the list of 

model type handle available policies to associate with the selected application 

model condition value (SpectroPHONE™ in this example, available from 

model security string 40 Cabletron Systems, Inc.). Pressing OK makes this window 

alarm ID disappear and the modified association is displayed in the 



alarm time 



Associations window (FIG. 4). 



alarm probable cause 2.4 Scheduler Window 

alarm status 45 j^c Scheduler window is illustrated in FIG. 7. Pressing 

event message associated with alarm the Associate button brings up the Modify Association 

assigned repair person window illustrated in FIG. 6. In the Modify Association 

user-clearable flag window, the user picks a policy from the list of available 

One exception to this is that an IP subnet address may be , n P olicies t0 associate with the selected application 

specified as a filter criterion, but the full IP address of the (SpectroPHONE™ in this example). In the Scheduler 

device that created the alarm is passed in the alarm notifi- wmd ° w > the r then f esses the Fre q ue ncy button to 

cat | on specify the frequency of the association. The Frequency 

A notification that an alarm has been cleared or updated °P tions are: 0n <* > Hourl * Dail * Weekl y and Monthl y- ™ e 

is sent to an application when SANM receives such a « information m the area below the Frequency button changes 

notification from SPECTRUM™, but only if the alarm dependmg on what frequency option is selected as follows: 

which is being cleared or updated was initially sent to the The 0nce °V^on allows the user to specify the month, day 

application when it occurred (i.e., it passed the filter criteria anc * start-time. 

for that application). The Hourly option allows the user to specify the number 



2.0 Configuration Tool 60 



of minutes after each hour. 
The Daily option allows the user to specify the time. 
The SANM Configuration Tool enables the user to define The Weekly option allows the user to specify the day of 

Alarm Notification Policies and to associate these policies the week and the time. 

with the applications that use SANM. The Monthly option allows the user to specify the day of 

The Configuration Tool is invoked by selecting Alarm 65 the month and the time. 
Notification Manager from the asterisk menu of Spec- Once the desired scheduling options have been selected, 
troGRAPH™. pressing, the Add button inserts the scheduling information 
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into the Scheduled Entries portion of the window. Further name, or Save As can be selected to save the modified policy 

entries can be added by repeating the previous steps. Entries under a different name. 

can be modified and removed by selecting them and using ^ information in the 0 Poli window can ^ 

the Modify and Remove buttons. ^ priflted by sdecting print from the Fi[e meQU 

2.5 Policies Window 

The Policies Window is illustrated in FIG. 8. This window 21 New Policy Window 

shows all currently defined policies. ^ New window is iUustrated in FIG. 12. The 

A new policy is created by selecting New from the File operations that can be performed in the New Policy window 

menu. This causes the New Policy window (FIG. 12) to 10 are the same as those performed in the Open Policy window 

appear. (FIG. 9). No filter parameters initially appear within Filter 1, 

An existing policy is viewed and modified by selecting therefore the first operation that needs to be performed is to 

the policy and then selecting Open from the File menu. This select a filter parameter by pressing the Parameter button 

causes the Open Policy window (FIG. 9) to appear. within Filter 1. All filter parameters are available from the 

An existing policy is deleted by selecting the policy and 15 pop-up menu at this point because the filter does not yet 

then selecting Delete from the File menu. The selected contain any filter parameters. 

policy is deleted after the user confirms the operation in a A new ^ saved by Meeting Save As from the File 

Confirmation Dialog window (not shown). menu and QniCTing the name for me policy in a dialog box> 

2.6 Open Policy Window 20 

He open Policy window is illustrated in FIG. 9. This 3 0 Inte g rati °" SANM and Application 

window shows all the filters that make up the policy. In the Adeveloper would use the following interface to integrate 

example shown w FIG. 9, Filters 1 and 2 are visible, but an application written ^ c or c++ ^ the Spectrum™ 

subsequent filters can be viewed using the scrollbar on the alarm mechanism 

right of the window. Similarly, the other filter parameters for 25 

Filter 1 and their associated values can be viewed using the An application using SANM to receive alarm notifications 

scrollbar below the Filter 1 filter parameters. and t0 clear/acknowledge alarms requires two separate 

To modify the displayed policy, Edit must be selected Processes, as illustrated in FIG. 13. 

from the File menu. The View item in the menu bar then As an example of how these two separate processes would 

becomes Edit. Once in Edit mode, multiple values for a 30 be used in an application, the ARS Gateway™ product 

particular filter parameter can be deleted or negated by would use Process 1 to receive filtered alarms from SANM, 

selecting the values and pressing the Delete or Negate format them into Trouble Tickets and put them into the ARS 

button. Values can be added for a particular filter parameter Database. Process 2 would be used when a user viewing a 

by pressing the filter parameter button (e.g. Landscape or particular Trouble Ticket pressed a clear or acknowledge 

Model Type). This brings up a separate window containing 35 button in the Trouble Ticket. 

a lis. of available values from which multiple values can be Two different programming paradigms are required for 

selected. An example of this window is shown in FIG. 10. ^ , w processes lhat ^ SANM: 

Filter parameters may be added to a filter by pressing the 

Parameter button within the filter. A pop-up menu appears For lhe P rocess that receives alarm notifications from 

containing all eight filter parameters. However, those filter 40 SANM, an asynchronous callback paradigm is used. This 

parameters which are already present in the filter are greyed- means that when me application code registers with SANM 

out and cannot be selected. Selecting one of the available to receive alarms, it hands program control over to SANM. 

filter parameters from this menu causes the new filter When SANM needs to send an alarm notification to the 

parameter and associated value box to appear in the filter. application, the application receives a callback from SANM. 

The alarm age for a particular filter can be modified by 45 ™* P rocess 15 termiDated b V il a TERM (terminate, 

pressing the Age button in the Open Policy window. This ' signal. 

brings up the Alarm Age window shown in FIG. 11. The For the process that clears or acknowledges alarms, 

values for the Hours and Minutes fields initially contain the however, a synchronous paradigm is used. This means that 

values from the Age text field in the Open Policy window. 5Q the application code in this process has program control. 

These values can be modified using the up and down arrow When this application code makes a call to the SANM API 

buttons for hours and minutes. to clear or acknowledge an alarm, the call blocks the 

A filter tag can be modified in the Open Policy window by application until it is finished, 
typing directly into the Tag text field of a filter. 

A new filter may be added to the policy displayed in the 5S 3.1 Definitions and Data Structures 
Open Policy window by pressing the Create Filter button. 

This will cause a new filter with no filter parameters to be M{ definitions and data structures are contained in the 

added to the end of the fist of filters. SANM header file sanm.h and are described below. 

An existing filter may also be duplicated. To do this the The prototype for the application's callback functions is 

filter to be duplicated must first be selected by clicking 60 defined as follows: 
within the filter label field (e.g. the area around the label 
Filter 2) and then pressing the Duplicate Filter button. Doing 

this causes a new filter, containing the same filter parameters typedcf void (*SANMCb) (struct SANM_Aiarm_Notify *); 
and values as the selected filter, to be added to the end of the 

filter list. This new filter can then be modified. 65 All the data in an alarm notification is contained in the 

After modifying a policy, Save can be selected from the SANM^Alarm_Notify structure, which is defined as fol- 

File menu to save the modified policy under its existing lows: 
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-continued 



struct SANM^Alaim_Notify{ 



char *model_name; 


oANMUIong 


model nandle; 


char 


*model__type_name; 


SANMUlong 


model type handle \ 


int 


condition_value; 


char 


*security_string; 


SANMUlong 


aIarm_ID; 


SANMTimestamp 


alann_time; 


SANMUlong 


cause code; 


char 


•probable cause; 


char 


*alarm^status; 


char 


*event_message; 


char 


*repair_person; 


char 


*IP_address; 


char 


•location; 


SANMUlong 


severity; 


SANMUlong 


alarm_age; 


char 


•SpectroSERVER_host; 


char 


•landscape; 


SANMBoolean 


user__clearable; 


char 


*ftlter_tag; 



RETURN VALUES 



SANM_RCV_ALARMS 
SANM_CLR_ALARMS 



The return value will be one of 
the following values; 
SANM_RETURN_OK 



10 



20 



All errors and warnings are defined in the enumeration 
SANM_error as follows: 
enum SANM__error 
{ 

SANM_RETURN„OK, 
SANM_INVALID_ALARM, 
SAN M_INVALID_LAND SCAPE, 
SANM_ALARM_NOT„CLEARABLE, 
SANM_REGISTER_ERROR 



25 



3.2.2 SANMRegister 

NAME 

SANMRegister — register with SANM 
SYNOPSIS 

//include "sanm.h" 

SANM_error SANMRegister (SANMCb set_cb, 
SANMCb clcar_cb, 
SANMCb update_cb); 
DESCRIPTION 

SANMRegister registers the application to receive 
alarm notifications from SANM. By calling this 
function, the application hands program control over 
to SANM until one of the application's callback 
functions is called. 



30 



3.2 Functions 

The functions that make up the SANM C/C++ API are 
described in the following sections in manual page format. 

3.2.1 SANMInit 
NAME 

SANMInit — initialize interaction with SANM 
SYNOPSIS 

#include "sanm.h" 
SANM_error SANMInit (char *application_name, 

SANMBoolean rcv_or_clr); 
DESCRIPTION 
SANMInit serves to initialize the program for interac- 
tion with SANM. This function should be called 
from within both application processes before any 
other function in the SANM API, 



35 



40 



45 



50 



INPUT ARGUMENTS 



applies tion_name 



rev_or_clr 



the name which must be used by 
the user to identify this 
application when using the 
Configuration Tool to associate 
a policy with it. 
a flag which indicates whether 
this process is going to receive 
alarm notifications or clear/ 
acknowledge alarms. The flag 
can take either of the following 
two values: 



55 
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INPUT ARGUMENTS 



set_cb 



clear_cb 



update_cb 



RETURN VALUES 



the name of the function that 
SANM will call in order to send 
an alarm notification for a new 
alarm. All applications must 
pass a valid function for this 
parameter. 

the name of the function that 
SANM will call in order to send 
an alarm notification for a 
cleared alarm. This parameter 
can be NULL if the application 
does not want to receive 
notifications for cleared alarms, 
the name of the function that 
SANM will call in order to send 
an alarm notification for an 
updated alarm. This parameter 
can be NULL if the application 
does not want to receive 
notifications for updated alarms. 



In normal operation, this 
function will never return. 
However, if it fails, one of the 
following errors will be 
returned: 

SANM_REGISTER_ERROR 



3.2.3 SANMClear 

NAME 

SANMClear — clear an alarm 
SYNOPSIS 

^include "sanm.h" 
SANM_error SANMClear (SANMUlong alarro_ID, 

char * landscape) 
DESCRIPTION 

SANMClear clears an alarm in SPECTRUM. An appli- 
cation can only clear alarms for which it received 
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notifications from SANM. Also, the user_clearable 
flag must have been set to CLE ARABLE in the 
alarm notification 



INPUT ARGUMENTS 




alarm-ID 


the ID of the alarm to be cleared 


landscape 


the landscape that generated the 




alarm 


RETURN VALUES 




status 


The return value will be one of 




the following values: 




SANM_RETURN_OK 




SANM_JNVALID_ALARM 




SANM_INVALID_LANDSCAPE 




SANM_ALARM_NOT_CLEARABLE 



3.2.4 SANMack 

NAME 

SANMAck — acknowledge an alarm 
SYNOPSIS 
#include "sanm.h" 

SANM__error SANMAck (SANMUlong alarm__ID, 
char landscape); 
DESCRIPTION 

SANMAck acknowledges an alarm in SPECTRUM. 
An application can only acknowledge alarms for 
which it received notifications from SANM. 



INPUT ARGUMENTS 




aIarm_JD 


the ID of the alarm to be 




acknowledged 


landscape 


the landscape that generated the 




alarm 


RETURN VALUES 




status 


The return value will be one of 




the following values; 




SANM_RETURN_OK 




S AN M__INVALID_ ALARM 




S ANM_IN VALI D__LANDSCAPE 
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The present embodiments may be implemented in a 
general purpose computer 70 as shown in FIG. 14. The 
general purpose computer may include a computer process- 50 
ing unit (CPU). 71, memory 72, a processing bus 73 by 
which the CPU can access the memory, and interface 74 to 
the rest of the alarm notification manager. 

In alternative embodiments, the invention may be a com- 
puter apparatus which performs the functions of any of the 
previous embodiments. Alternatively, the invention may be 
a memory, such as a floppy disk, compact disk, or hard drive, 
that contains the computer program or data structure, for 
providing to a general purpose computer instructions and 
data for carrying out the functions of the previous embodi- 
ment. 

Having thus described certain particular embodiments of 
the invention, various modifications will readily occur to 
those skilled in the art which are intended to be within the 
scope of this invention. Accordingly, the foregoing descrip- 65 
tion is by way of example only, and not intended to be 
limiting. 
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What is claimed is: 

1. A method of alarm notification comprising actions of: 

(a) receiving alarms from multiple network management 
servers; 

(b) assigning policy-based filters to associated network 
management applications; and 

(c) applying the assigned policy-based filters to the alarms 
and for the alarms which pass the filters, generating an 
alarm notification and forwarding the same to the 
associated network management application. 

2. The method of claim 1, wherein: 

the action of assigning includes assigning a plurality of 
filters comprising a policy to the associated network 
management application. 

3. The method of claim 2, wherein: 

each filter comprises at least one filter parameter; and 
the action of applying comprises performing a logical 
AND of all parameters within one filter and performing 
a logical OR between all filters within one policy. 

4. The method of claim 3, wherein: 

the action of generating includes specifying real-time 
values of each filter parameter in the alarm notification. 

5. The method of claim 2, wherein: 

the action of assigning includes storing a policy name and 
the associated applications in a database accessible to 
all servers. 

6. The method of claim 1, wherein: 

the action of assigning includes assigning a tag to each 
filter. 

7. The method of claim 6, wherein: 

the action of generating includes specifying the tag for the 
filter which the alarm passed in the alarm notification. 

8. The method of claim 1, wherein: 

the action of assigning includes storing the filters in a 
database. 

9. The method of claim 1, wherein: 

the action of generating further includes specifying a user 
name in the alarm notification to enable the application 
which receives the alarm notification to notify a user 
having the specified user name. 

10. The method of claim 1, wherein: 

the action of assigning includes scheduling the assigning 
to occur at a specified time. 

11. The method of claim 1, further comprising: 

(d) following resolution of an alarm, forwarding an alarm 
clear message to the associated network management 
applications. 

12. The method of claim 1, wherein: 

the action of assigning includes assigning the same filters 
to multiple associated network management applica- 
tions. 

13. The method of claim 1, wherein: 

the action of assigning is performed by a user via a 
graphical user interface. 

14. The method of claim 1, wherein: 

the action of generating includes generating an alarm 
notification which contains information about the 
device which generated the alarm. 

15. The method of claim 1, further comprising: 

one or more of the network management applications 
generating an alarm clear message and forwarding the 
same to the network management server which gener- 
ated the alarm. 
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16. An apparatus for alarm notification comprising: 22. The method according to claim 17, wherein the action 
a database of policy-based filters; of creating includes assigning a tag to each filter. 

. 4 - - . . ,. . . - lt 23. The method according to claim 22, wherein the action 

a user interface for assigning policy-based filters to asso- of tin spec f fyirjg thc tag for the mtcr which 

ciated network management applications; $ pa * ssed m th / alarm n * tificat f orit 

a processor and a memory device containing a program of 24. The method according to claim 18, wherein the action 

instructions for the processor which instructions of creating includes storing the filters in a database, 

include: 25. The method according to claim 18, wherein the action 

means for receiving alarms from a plurality of network of generating further includes specifying a user name in the 

management servers; alarm notification to enable an application which receives 

means for applying policy-based filters to the alarms the alarm notification to notify a user having the specified 

and generating an alarm notification for those alarms user name. 

which pass the filters; and 26. The method according to claim 18, wherein the action 

means for forwarding the alarm notification to the of creating includes scheduling the creating to occur at a 

associated network management applications. specified time. 

17. A method for performing alarm notification compris- 21 • 7^ m f j^?^ 11 ^ l ° c ! aim ? 8 > &l 1 rthcr comprising 
• ne . an action of (d) following resolution of an alarm, forwarding 

,\ . _ . . . , an alarm clear message to the at least one management 

(a) receiving a plurality of alarms from a plurality of application 

management servers; 28 ^ mcthod according t0 claim 18> whcrcin the action 

(b) creating, in response to a user action, a plurality of 20 0 f crea ting includes assigning the same filters to multiple 
policy-based filters; and management applications. 

(c) applying the policy-based filters to the received plu- 29. The method according to claim 18, wherein the action 
rality of alarms, generating an alarm notification and of creating is performed by a user via a graphical user 
forwarding the same to at least one management appli- interface. 

cation. 25 30. The method according to claim 18, wherein the action 

18. The method according to claim 17, wherein the action of generating includes generating an alarm notification 
of creating includes creating a plurality of filters comprising which contains information about the device which gener- 
a policy. ated the alarm. 

19. The method according to claim 18, wherein each filter 31. The method according to claim 18, further comprising 
comprises at least one filter parameter, and the action of 30 the at least one management application generating an alarm 
applying comprises performing a logical AND of all param- clear message and forwarding the same to the management 
eters within one filter and performing a logical OR between server which generated the alarm. 

all filters within one policy. 32. The method according to claim 17, wherein the 

20. The method according to claim 19, wherein the action plurality of management servers are network management 
of generating includes specifying real-time values of each 35 servers. 

filter parameter in the alarm notification. 33. The method according to claim 17, wherein the at least 

21. The method according to claim 18, wherein the action one management application includes at least one network 
of creating includes storing a policy name and at least one management application. 

associated management application in a database accessible 

to all servers. ***** 
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